The Level 2 (or L2) cache is part of a multiple level storage strategy for data stored by computer central processing units (CPUs). The multiple level caching scheme bridges the gap between: (i) the relatively fast CPU; and (ii) the relatively slow random access memory (RAM). The L2 cache is typically built into the motherboard, but some CPUs now incorporate an L2 cache. Typically, L2 caches are associative and characterized by a number of “ways” and a number of “sets.”
The L2 cache may be locked using a Replacement Management Table (RMT). The cache has a copy of recently fetched instructions, or recently accessed data in memory which enables the processor to access these locations faster. Sometimes for performance enhancement it would be required to maintain certain memory locations in cache permanently so that accesses to these locations will always get cache hits. Cache locking prevents replacement of instructions or data entries stored in the cache. Cache locking can be done for the entire cache or for individual ways in the cache.
A Replacement Management Table (RMT) is typically used for cache locking when one or more of the n ways of an n-way associative cache are not eligible to be replaced for a given classID, which is specified in range registers. The number of ways to be locked is typically specified using RMT setup registers. The general validation process of RMT locking and the phases involved in RMT cache locking, in order, are as follows: (i) test case generation; (ii) test case execution; and (iii) error checking. Some embodiments of the present disclosure focus on the foregoing phases (i) and (ii), and allow for the use of any checker method in phase (iii), so long as the checker method is supported by the validation support tool.
Bringing addresses from memory to cache, as “instruction fetches” using instruction range registers, entails many challenges. Some conventional techniques will now be described in the following paragraphs.
Normal code execution happens sequentially, thus executing all instructions in a current cache line (depending on the cache line size) before proceeding to the next cache line. Bringing a line to cache requires execution of only one instruction per line. Loops in the code stream will lead to the same instructions being executed repeatedly. For this reason, execution of a set of bulk instructions in sequential mode can be a less than optimal approach for creation (also called “population”) of valid lines in the to-be-locked cache way.
The following table shows the number of sequential instructions to be executed, in the worst case scenario for population of an 8-way associative, 1 megabyte (MB) L2 cache with cache line size of 128 bytes (that is, 1024 bits per cache line):
Number of ways to beNumber of sequentialpopulated and lockedinstructions to be executed132*1024264*1024
As will be appreciated from the above table, writing specific code of a sequential nature for verification of L2 Cache Locking can make the entire validation tool (that is, the executable file used to implement the tool) more bulky and less scalable, depending on the coverage required.
Another technique for validation of L2 cache locking is re-execution of a random test case, first for locking and then for verification. However, this approach does not guarantee that all the cache lines, in the way to be locked, are populated with test case information. For example, in random test cases, pages in the virtual memory may be mapped to discontinuous pages in the real memory. The L2 cache is populated based on the real address of the instruction/data to be fetched. For this reason, cache lines can potentially be fetched in a disordered manner. This technique also does not necessarily allow a systematic approach for post-locking verification of the content in a locked way.
Another technique for validation of L2 cache locking is execution of loads and stores of data for populating valid lines and locking the valid lines in the L2 cache. This technique does not use instruction side registers and corresponding locking mechanisms. For this reason, this technique prevents validation of the instruction side facility provided for purposes of L2 cache locking.